Disaster recovery or business continuity plans deal with, among other things, the restoration of computer systems, software, network connections, etc. to partial or full functionality following the occurrence of a loss of such systems (usually due to external forces). Where databases are part of such system, the plans must include some means by which the lost data is recovered or restored. Indeed, it is often the data rather than the physical system components which is most critical for a business' operations and so the restoration of that data is often of paramount importance.
Notwithstanding the importance of such data, however, because disaster recovery operations for large data centers and/or large databases are often both complex and costly to implement, businesses are sometimes reluctant to implement disaster recovery mechanisms. The problem is compounded when the data to be safeguarded is changing at a fast rate; the synchronization of the disaster recovery database(s) can require high bandwidth connections and complex synchronization tools.
Even where disaster recovery mechanisms have been implemented, conventional solutions often rely on mass backups of data to tape or other storage medium. These solutions fail to account for differing degrees of importance of individual data items. Consequently, if and when a computer system must be restored from such a backup, meaningful data (e.g., from a standpoint of an application program) cannot be differentiated from less important data and so an entire reload of the database is required. This can add unnecessary time to the restoration process, which could be saved if the data were better segregated or other means of restoring data according to the needs of the application programs requiring the same were followed.